- Petites notions de sécurité, ethical hacking, robustesse, bounties

- Les principales failles (Déni de Service, Diffusion d'information, Injections)

- Les petites choses à savoir pour construire une appli web sécurisée

$ whoami

@regilero (Twitter/Stack Overflow/Github)

Demain, dans 6 mois, l'année prochaine, ou même peut-être hier, vous mettrez en ligne un site internet. Ou bien on vous demandera de participer à la réalisation d'un de ces sites.

• Êtes-vous capable de juger du niveau de sécurité de ce site?
• Avez-vous respecté les bonnes pratiques du métier?
• Savez-vous vous poser les bonnes questions?
• Est-ce que l'on va vous rappeler un dimanche matin à 7h ?

Mais aussi parce que réfléchir aux problématiques de la sécurité pour vos programmes:

* est très formateur

* vous force à lire des documentations

* est amusant

• Voyez cela comme un défi
• Trouver des failles dans un système est une pensée très proche de la pensée qui permet de concevoir ces systèmes. Mais c'est une pensée plus récréative.
• Offrez des chocolats/bières à vos collègues
• Payez des hackers (bounty)

Vous apprendrez beaucoup en étant d'un côté comme de l'autre.

Vous augmenterez le niveau de sécurité de façon ludique avant d'avoir à le faire dans l'urgence et dans des situations qui ne sont pas du tout agréables.

• Connaissez-vous vraiment le protocole HTTP?
• Maîtrisez-vous les différences subtiles entre un GET et un POST?
• Savez-vous ce que fais jQuery.ajax()?
• Connaissez-vous les cookies js? les cookies flash?
• Savez-vous à quoi sert le fichier crossdomain.xml?
• Saviez-vous que le svg pouvais contenir du javascript?
• Comprenez-vous quelque chose à openid?

Pour permettre aux développeurs de travailler sans imposer une formation professionelle de dix ans, les outils mis en place fournissent des niveaux d'abstraction.

Les failles de sécurité utilisent le plus souvent des cas limites de ces abstractions. Et si vous voulez progresser, il faudra toujours essayer de voir plus loin que les abstractions que vous manipulez. Effectivement, il n'y a pas de fin, mais cela fera de vous un meilleur développeur, jour après jour.

All non-trivial abstractions, to some degree, are leaky
--Joel Spolsky
The Law of Leaky Abstractions

Le domaine de la sécurité est très vaste. Il regroupe des éléments plus larges que ceux que nous aborderons pour la sécurité web:

• les procédures humaines autour du système d'information
• les failles dans le comportement humain (social engineering)
• la sécurité matérielle, les accès physiques aux systèmes
• la gestion des sauvegardes, de la redondance, de la résistance aux pannes
• (...)

Trop de sécurité tue la sécurité.

Quand le niveau de sécurité augmente, le niveau de confort descend (le plus souvent).

Si le niveau de sécurité en place est trop fort, les utilisateurs mettrons en place des moyens dérivés qui ruinerons le travail effectué.

Une fois que vous aurez acquis des connaissances en terme de sécurité, il faudra être capable de les doser et de les relativiser par rapport à une vision plus large du système d'information.

Votre serveur web peut être pris pour cible pour plusieurs raisons:

• Ses capacités en terme de calcul et d'accès au réseau (pour les spambots, des DDOS, du stockage de fichiers)
• Pour le plaisir, le défi
• Pour les données qu'il abrite
  • Les mots de passe des utilisateurs sont souvent identiques d'un site à l'autre
  • Il se peut que certaines données ne soient pas destinées à être publiques
• Pour nuir, pour du chantage (un site rendu inaccessible par un DOS)

L'immense majorité des attaques informatiques ne proviennent pas des pédos nazis de l'Internet.

Elles sont le plus souvent effectuées en interne, par vengeance, par frustration, etc.

Il ne faut pas négliger le potentiel de nuissance des utilisateurs autorisés de l'application. Ce qui peut être aggravé aussi par les risques de mauvaises manipulations pour les rôles utilisateurs qui possèdent trop de droits ou à cause des mauvaises pratiques renforcées par l'application.

Informer sur la sécurité, donc.

En terme de sécurité informatique le savoir est ouvert et disponible.

• Il est facile d'acquérir très vite les principales connaissances
• Ce savoir peut être utilisé pour créer et réparer (makers, hackers) ou pour détruire (manque de maturité, retard de développement social et individuel, lulz, etc.)

Du côté obscur de la force le chemin plus facile semble...

Dans le domaine particulier de la sécurité on utilise souvent deux termes pour distinguer ces individus: Black Hat et White Hat, la différence est la même que chez les magiciens.

• Ne diffusez pas publiquement de failles de sécurité exploitables, pas même sur les bug trackers publiques du projet. Pas de 0 day.
• Signalez-les aux équipes dédiées et laissez leur le temps d'analyser et de corriger le problème
• Soyez patients, ce temps peut être très long
• La publication en désaccord avec les gestionnaires du projet peut exister mais doit être justifiable (non prise en compte de l'alerte, mise en danger des utilisateurs, etc.)

Devenir un expert dans le domaine peut devenir complexe car il faut pouvoir apréhender un grand nombre de domaines.

Mais sans parler d'expertise, il faut

Appliquer des recettes

Prendre des habitudes

Lire contrôler des choses déjà compilées par vos pairs.

• OWASP TOP 10 (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)

La grande différence entre du code produit par un débutant et celui produit par un développeur expérimenté réside souvent dans le niveau de rigueur.

/*
 * Feed $arr with the bar key from $toto and arr['foo']
 */
function foo($toto, &$arr) {
  $bar = $toto->tata . $arr['foo'];
  $arr['bar'] = $bar;
}

Le code marche (il fait la tâche bizarre qui lui est demandé).

Mais s'il est utilisé en dehors du cadre pour lequel il a été pensé, il peut échouer de façon plus ou moins brutale. Cela va de la génération de WARNING (accès à une clef non existante) au crash complet (accès à un attribut inexistant).

Be conservative in what you do, be liberal in what you accept from others

/*
 * Feed the bar key of $arr array with $toto->tata and arr['foo']
 *
 * If toto->tata is not yet initialised defaults will be loaded
 *
 * @param ZooInterface $toto Main Zoo object
 * @param array $arr array used by reference, result in case of success is in arr['bar']
 * @throws FooException
 */
function foo(ZooInterface $toto, &$arr) {
  if (!(is_array($arr)) || !array_key_exists('foo',$arr)) {
    throw new FooException('Second argument of foo should be an array with the foo key already set');
  }
  try {
      if (!isset($toto->tata)) {
        $toto->tata = ZooBase::loadTataDefaults();
      }
      (...)

      (...)
      $bar = $toto->tata . $arr['foo'];
      if (array_key_exists('bar',$arr)) {
        if ($bar === $arr['bar']) {
          $this->log('bar key was already set and is unaltered while running foo.')
        } else {
          throw new FooAlterationException('found a bar kay with a different value while running foo');
        }
      } else {
        $arr['bar'] = $bar;
      }
  } catch (Exception $e) {
    throw new FooException('Foo was unable to make the job!', $e);
  }
}

Always wanted to travel back in time to try fighting a younger version of yourself? Software development is the career for you! - twitter: Elliot Loh @Loh

La robustesse est importante en terme de sécurité parce que l'attaquant ne va pas respecter les règles.

Un code peu robuste est non sécurisé

Un des aspects important de l'attaque de sécurité est l'utilisation du code et des outils qui sont en place en les détournant (hijacking). L'attaquant se sert de tout ce qui est présent et en détourne l'usage.

• Toute erreur qui démontre une absence de robustesse est potentiellement un vecteur d'attaque

De la même manière qu'en mathématiques, la phrase magique "Si x est différent de 0" devait devenir un mode de pensée obligatoire, le développeur devrait toujours penser aux cas limites, à ce qui arrive quand le contrat n'est pas respecté, quand on ne respecte pas les règles.

• CVE : Common Vulnerability Exposure

Diffuser l'information pour mieux se protéger, mais aussi pour en comprendre les impacts:

• Impact sur la confidentialité
• Impact sur l'intégrité des données
• Impact sur la disponibilité
• Complexité d'accès
• Authentification requise?
• Escalade de privilèges?

• Type de vulnerabilité

• CVE-1999-1293 mod_proxy, DOS, core dump (10.0)

• CVE-2013-1643 PHP SOAP

Déni de Service

Information Disclosure

Injection

Le site web est rendu inaccessible, ce qui ouvre la voie aux concurrents ou au chantage. Il y a plusieurs vecteurs:

• monopolisation des ressources (sockets, mémoire, processus serveur, disque dur, etc)
• traitements trop longs (donc monopolisation du CPU)
• destruction des ressources (crash serveur)
• autres (cache poisonning, DNS poisoning, ...)

Mais ces informations qui aident vos attaquants se cachent à de multiples endroits:

Ici, nous avons la version d'Apache httpd, la version de PHP, l'OS (gentoo) et même la version d'OpenSSL.

Retenez:

• Il ne faut pas faciliter la tâche à votre assaillant
• Ne lui donnez pas la liste des failles qu'il peut tenter
• Un serveur qui "parle" trop incite l'assaillant à tenter plus de choses, cela démontre un faible niveau de sécurité
• Chaque information peut-être réutilisée (pensez social engineering)
• Si vous affichez des informations inutiles, pensez à tromper votre assaillant

Presque toutes les failles sont des failles d'injection, si on veut. -- Moi.

En mieux:

SQL injection is a special case of syntax tree mutation. All languages are susceptible to it, and everything is a langage. #langsec - twitter: active wreck chords @jcoglan

Mon petit violon d'Ingres.

• "Empoisonnement de cache", "Contrebande HTTP", "Division de réponse"
• jouer sur les interpretations différentes de messages HTTP entre les serveurs caches et les serveurs applicatifs
• injecter du contenu de "header +body HTTP" dans un Header HTTP comme "Location".
• jouer sur la taille des messages transmis (Content-Length, Chunked Transfer, dépassements d'entiers, etc)
• HAProxy est votre meilleur allié

Entrées et Sorties

Sécurité en profondeur

Blindage de configuration

Principe du KISS

• Keep It Stupid Simple

Décomposez les tâches complexes en sous-ensemble simples, appréhendables

Boîte Noire, Flux In flux Out

Chacune de ces tâches peut être vue comme une boîte qui accepte des entrées et génère des sorties:

La boîte noire se décompose elle-même en un sous-ensemble de boîtes qui interagissent. Il y a des flux entrants et sortants pour chacune.

Ce principe est aussi applicable à l'ensemble.

Filtrez les sorties

Validez les entrées

Filtrez les sorties

Validez les entrées

Filtrez les sorties

Validate INPUTS

Filter OUTPUTS

Validez les entrées

Filtrez les sorties

Validez les entrées

Filtrez les sorties

Validez les entrées

Filtrez les sorties

• Le texte brut est par nature complexe (encoding utf-8?)
• Si vous souhaitez dès la validation des entrées n'accepter qu'un sous ensemble du HTML, faites très attention aux expressions régulières HTML can't be parsed by regex
• faites attention aux messages de rejets, c'est peut-être ce message d'erreur qui est ciblé par le contenu.

source XKCD: http://www.xkcd.com/1137/

Les règles d'échappement sont propres à chaque sortie et visent à éviter le principe des attaques par injection.

• Page HTML -> balises HTML -> encodage de caractères HTML ('<' => &lt; 'é' => &eacute;)
• url -> encodage d'URL -> (espace => %20, '=' => %3D, etc.)
• Fichier CSV -> séparateurs ',' ; des délimiteurs '"', retours chariots, etc.
• Fichier sur disque: chemins, caractères spéciaux
• SGBD -> échapper le SQL, paramétrer

Ces filtrages sont propres à chaque sortie ==> ils ne doivent normalement pas être effectués à la validation, en entrée, puisqu'ils sont différents en fonction des canaux de sortie.

Une sortie non ou mal filtrée est la base de la majorité des attaques de sécurité dans le domaine du web.

Si vous ne devez retenir que deux choses retenez ces éléments là.

Validation des entrées, Filtrage des sorties.

Face à un projet essayez d'identifier très vite les éléments qui servent à ces deux tâches.

Ce principe est le deuxième grand principe (après les validations et filtrages). Les différentes couches, ou strates, d'un système d'information ont toujours des failles. Ne faites jamais une confiance aveugle aux autres briques de la solution.

Ne faites jamais confiances aux étapes précédant votre code pour bloquer les attaques!

• Vous limiterez les dégats en cas de faille
• Vous compliquerez la découverte des failles (en cas d'absence de réponse positive, l'assaillant ne sait peut-être pas qu'il avait passé avec succès l'une des barrières)

Soyez paranoïaques, on parle de systèmes automatisés, ces systèmes ont très peu de bon sens, ils peuvent laisser entrer un éléphant dans votre salon si celui-ci conduit votre voiture, porte votre cravate et possède les clefs de la maison.

(photo elephant: banksy)

• Prenez l'habitude de tester votre application avec des contenus limites
• utilisez des outils: metasploit, nessus, etc.
• utilisez vos collègues (bounty)

Un projet peut être très mauvais en terme de sécurité et avoir du succès.

Ne surestimez pas vos pairs, encore moins les utilisateurs, et, surtout, pensez aux commerciaux.

Un produit sécurisé est souvent identique fonctionnellement au même produit sans la sécurité et sans la robustesse.

Que vaut la sécurité quand les plates-formes changent tous les ans, que le marché s'emballe pour la nouveauté?

Jusqu'ici tout va bien...

Ce principe est l'une des applications du principe précédent. Une application sécurisée n'existe pas si le système d'information qui héberge cette application n'est pas pris en compte.

Pour aujourd'hui, je ne vous ferais pas un cours détaillé sur l'administration système mais je liste quelques principes:

• isolement, cloisonnement
• restriction de droits, création de rôles par droits
• supervision des ressources
• connaissance des paramètres de configuration
• conservatisme (le bon sysadmin est souvent moins hype que le développeur web)

Regardez les headers HTTP de sites comme github ou facebook et voyez si votre site ne mériterait pas les mêmes.

GRANT ALL PRIVILEGES ON `db_user1`.* TO 'user1'@'%';
GRANT ALL PRIVILEGES ON `db_user2`.* TO 'user2'@'%';
GRANT ALL PRIVILEGES ON `db_user%`.* TO 'user%'@'localhost';
GRANT SELECT ON `db_user%`.`foo` TO 'bar'@'localhost';

GRANT ALL PRIVILEGES ON `db\_user1`.* TO 'user1'@'%';
GRANT ALL PRIVILEGES ON `db\_user2`.* TO 'user2'@'%';
GRANT ALL PRIVILEGES ON `db\_user\%`.* TO 'user%'@'localhost';
GRANT SELECT ON `db_user%`.`foo` TO 'bar'@'localhost';

MYSQL: The “_” and “%” wildcards are permitted when specifying database names in GRANT statements that grant privileges at the global or database levels.